OpenClaw Mission Control — Implementation Plan v2.0

Version 2.0 · Authored by Ada (subagent research run) · March 2026
Builds on PLAN.md v1.0 — adds multi-agent orchestration across Claude Code, Codex, Gemini CLI, OpenCode
Status: Research-complete. Ready for implementation handoff.

Executive Summary

What we're building: A self-hosted Mission Control UI that monitors all OpenClaw agent sessions and serves as the dispatch point for coding agents (Claude Code, Codex, Gemini CLI, OpenCode, etc.) — a true "glass pane" across all AI activity in Sean's homelab.

Why it's feasible: The integration problem is already solved. OpenClaw's ACP harness (via the acpx plugin) is a production-quality abstraction layer that runs Claude Code, Codex, Gemini CLI, OpenCode, and others through a unified protocol. ACP sessions appear as standard OpenClaw sessions with keys like agent:ada:acp:<uuid> and emit events on the same WebSocket that the Mission Control already taps. There is no new protocol to invent. Adding multi-agent orchestration to Mission Control is primarily a UI + dispatch feature, not a new backend integration.

Key insight from research: AionUi (18k ⭐) and agentsview (Go binary) already prove multi-agent monitoring is solved. But neither is OpenClaw-native or homelab-deployable the way Sean needs. We build what they can't: OpenClaw-native, Docker-deployed, Tailscale-accessible, with full dispatch+monitor in one UI.

Verdict: High feasibility. Moderate complexity increase over v1.

1. Feasibility Assessment

Claude Code — ✅ Excellent programmatic support

Claude Code (@anthropic-ai/claude-code) has a documented Agent SDK at platform.claude.com/docs/en/agent-sdk. CLI flags confirmed:

claude -p --output-format stream-json — JSONL streaming of all events (messages, tool calls, results)
claude -p --output-format stream-json --include-partial-messages — includes partial streaming
--session-id <uuid> — caller-specified session ID for tracking
--max-turns N — turn limit for automation
--permission-mode bypassPermissions — non-interactive mode (Claude Code's own flag)
--print / -p — batch/non-interactive mode, no TTY required
--json-schema — validated structured output
--fallback-model — model failover

Bottom line: Claude Code can be invoked as a subprocess with full JSONL event streaming. Session IDs are caller-controlled. This is first-class programmatic support. The acpx harness uses exactly this interface. No custom protocol work needed.

Codex (OpenAI CLI) — ✅ Subprocess-friendly

OpenAI Codex CLI (@openai/codex) is a Rust binary. From research: - Standard subprocess with stdout/stderr capture - No official event streaming API beyond stdout - CodexMonitor (2.7k ⭐, Tauri app) already orchestrates multiple Codex instances via subprocess management - The acpx harness bridges Codex through the same ACP protocol, abstracting the difference

Bottom line: Works via subprocess + stdout capture. acpx handles the complexity.

Gemini CLI — ✅ Subprocess-friendly

Google Gemini CLI (@google/gemini-cli, Apache 2.0): - npm package, terminal-first design - MCP support for custom integrations - Standard subprocess; no special event streaming API - acpx harness alias is gemini - AionUi confirms multi-agent cowork including Gemini works via subprocess management

Bottom line: subprocess + stdout, same pattern as Codex. acpx abstracts it.

OpenCode (SST) — ✅ Supported

acpx harness alias is opencode
AionUi and agentsview both confirm OpenCode support
Treated identically to Gemini/Codex in the acpx abstraction

OpenClaw ACP — ✅ The unified bridge (this is the key finding)

The acpx plugin is a first-party OpenClaw backend that: 1. Manages subprocess lifecycles for all coding agents (pi, claude, codex, opencode, gemini, kimi) 2. Translates their stdout into ACP protocol events 3. Surfaces those events on the OpenClaw Gateway WebSocket as standard session events 4. Provides session keys, state management, thread binding, and cancel/steer controls 5. Is already config-driven: acp.allowedAgents: ["pi", "claude", "codex", "opencode", "gemini", "kimi"]

ACP session keys follow the pattern: agent:<agentId>:acp:<uuid>

The Mission Control gateway adapter already receives all ACP session events — they look identical to regular OpenClaw session events. The monitoring problem is already solved.

Dispatch works via the same Gateway REST API: POST /sessions with runtime: "acp" and agentId: "codex" (or whichever agent). This is what sessions_spawn({ runtime: "acp", agentId: "codex" }) calls under the hood.

Common Interface — ✅ ACP protocol is the abstraction

UI Dispatch → Gateway REST API → acpx plugin → subprocess (claude/codex/gemini/opencode)
                                                    ↓
UI Monitor ← Gateway WebSocket ← ACP events ← acpx event normalizer ← stdout

All agents share the same event schema through this stack. The Mission Control doesn't need agent-specific adapters. One WebSocket, all agents.

Prior Art — Strong signals

Project	Stars	Relevance
AionUi	18,336	Proves multi-agent cowork (Electron). Use as reference for UX patterns.
agentsview	424	Go binary proving multi-agent transcript/analytics. Read-only but shows data model.
claude-octopus	1,082	Shell-based multi-agent router (Claude Code + Codex + Gemini in parallel).
Claw-Kanban	43	Direct precedent: kanban routing tasks to Claude Code, Codex CLI, Gemini CLI. Plugin architecture.
CodexMonitor	2,780	Tauri app orchestrating multiple Codex subprocess instances.
builderz-labs/mission-control	2,036	Best base to fork for OpenClaw-native web dashboard. Already has multi-agent support via gateway.

Hard Problems (where complexity lives)

Live output streaming — ACP sessions produce high-volume output. The WebSocket fan-out to browser clients must batch intelligently (OpenClaw's stream.coalesceIdleMs helps).
Permission mode — Coding agents in non-interactive ACP mode can fail on permission prompts. permissionMode=approve-all is the right default for unattended runs; make this configurable per dispatch.
Session TTL and cleanup — ACP sessions have runtime.ttlMinutes. Expired sessions need proper lifecycle handling in the UI (stale vs. complete vs. error).
Cross-agent comparison — Comparing output across agents running in parallel requires a clear data model (task → N agent sessions → results).
Dispatch UX — Picking agent, setting cwd, permission mode, task description — needs a well-designed modal that doesn't overwhelm.

2. Architecture — v2

The v1 architecture is correct and requires only targeted additions for multi-agent dispatch.

2.1 Component Map (additions over v1 in bold)

graph TB
    subgraph External["External Systems"]
        GW[OpenClaw Gateway\nWebSocket + REST API]
        ACPX[acpx Plugin\nACP Backend]
        CC[Claude Code\nsubprocess]
        CD[Codex CLI\nsubprocess]
        GEM[Gemini CLI\nsubprocess]
        OC[OpenCode\nsubprocess]
        GH[GitHub API]
        TG[Telegram Bot API]
    end

    subgraph Core["Mission Control Core"]
        GA[Gateway Adapter\nWebSocket client + REST\nreconnect, heartbeat, auth]
        EB[Event Bus\nnormalized events]
        AR[Agent Registry\nall sessions incl ACP]
        TQ[Task Queue]
        AL[Auth Layer]
        NR[Notification Router]
        AD["Agent Dispatcher\n(NEW)\nREST POST /sessions\nwith runtime:acp"]
        AM["Agent Manifest\n(NEW)\nknown agents + capabilities\ncurrent status per agent"]
    end

    subgraph UI["UI Shell"]
        WEB[Web App\nNext.js]
        DP["Dispatch Panel\n(NEW)\nagent picker + task form"]
        AR2["Agent Roster\n(NEW)\nunified view of all\nOpenClaw + ACP sessions"]
        CA["Cross-Agent View\n(NEW)\ncompare N sessions\nfor same task"]
    end

    subgraph Storage["Storage"]
        DB[(SQLite\nsessions, tasks, users)]
        CACHE[(Cache)]
        LOGS[(Event Log)]
        TM["Task Map\n(NEW)\ntask → [session_ids]\nfor cross-agent grouping"]
    end

    GW <-->|WebSocket events| GA
    GW <-->|REST commands| GA
    GW --- ACPX
    ACPX --- CC
    ACPX --- CD
    ACPX --- GEM
    ACPX --- OC

    GA -->|all events incl ACP| EB
    EB --> AR
    EB --> TQ
    EB --> NR
    AR --> DB
    AR --> CACHE
    EB --> LOGS

    AD -->|POST /sessions runtime:acp| GA
    AM --> DB

    NR -->|alerts| TG
    GA <-->|commands| GH

    WEB <-->|API + WS| EB
    DP --> AD
    AR2 --> AR
    CA --> TM
    TM --> DB

2.2 Key Architecture Decision: ACP as the Integration Layer

The Mission Control does not directly manage subprocess lifecycles. It delegates entirely to the OpenClaw Gateway + acpx plugin. This means:

No Docker sidecar for coding agents — they run where acpx runs (on the OpenClaw host)
No custom agent protocols — everything flows through the gateway WebSocket
Instant compatibility — when Anthropic adds a new claude-opus-5 or OpenAI ships a new Codex version, acpx handles it; Mission Control sees the same session events
Cancel/steer via /acp cancel and /acp steer — gateway commands, not direct process signals

2.3 New: Agent Manifest

A static config (+ live state) that the Mission Control maintains for the agent picker UI:

interface AgentManifest {
  id: string;          // "claude" | "codex" | "gemini" | "opencode" | "pi" | "kimi"
  displayName: string; // "Claude Code" | "Codex CLI" | etc.
  icon: string;        // emoji or icon URL
  capabilities: {
    streaming: boolean;
    multiTurn: boolean;
    maxConcurrent: number;
  };
  // Live state, updated from ACP session events
  status: "available" | "busy" | "error" | "unconfigured";
  activeSessions: number;
  lastUsed: Date | null;
}

This manifest is built from acp.allowedAgents in the gateway config + live session state.

3. Agent Adapter Pattern

Important finding: Because acpx normalizes all agents to ACP protocol, the Mission Control does not need per-agent adapters at the application level. The "adapter" is the acpx plugin itself. However, the Mission Control does need a dispatch abstraction for the UI layer.

3.1 AgentDispatcher Interface

interface AgentDispatcher {
  // Dispatch a task to a specific agent via Gateway REST
  dispatch(params: {
    agentId: "claude" | "codex" | "gemini" | "opencode" | "pi" | string;
    task: string;
    options?: {
      cwd?: string;
      mode?: "oneshot" | "persistent";
      permissionMode?: "approve-all" | "approve-reads" | "deny-all";
      model?: string;
      maxTurns?: number;
      maxBudgetUsd?: number;
      thread?: boolean;
      label?: string;
    };
  }): Promise<{ sessionId: string; sessionKey: string }>;

  // Stream events for a session (from Event Bus subscription)
  stream(sessionKey: string): AsyncIterator<AgentEvent>;

  // Get current status
  status(sessionKey: string): Promise<AgentSessionState>;

  // Cancel in-flight turn
  cancel(sessionKey: string): Promise<void>;

  // Steer a running session
  steer(sessionKey: string, instruction: string): Promise<void>;

  // Close session + remove bindings
  close(sessionKey: string): Promise<void>;
}

3.2 Implementation

The AgentDispatcher implementation issues commands to the OpenClaw Gateway REST API:

// dispatch() → POST /sessions
{
  "runtime": "acp",
  "agentId": "codex",
  "task": "Refactor the auth module to use Better Auth",
  "options": {
    "cwd": "/workspace/my-repo",
    "mode": "oneshot",
    "permissionMode": "approve-all"
  }
}

// cancel() → POST /acp/cancel?session=<key>
// steer() → POST /acp/steer { session: key, instruction: "..." }
// close() → POST /acp/close?session=<key>

All of these are thin wrappers around gateway REST endpoints. No direct subprocess management.

3.3 AgentEvent Schema (canonical, normalized by gateway)

type AgentEvent =
  | { type: "session.created"; sessionKey: string; agentId: string; task: string }
  | { type: "session.updated"; sessionKey: string; status: AgentStatus }
  | { type: "message.chunk"; sessionKey: string; content: string; partial: boolean }
  | { type: "tool.called"; sessionKey: string; tool: string; input: unknown }
  | { type: "tool.result"; sessionKey: string; tool: string; output: unknown; error?: string }
  | { type: "session.ended"; sessionKey: string; exitCode: number; cost?: number }
  | { type: "session.error"; sessionKey: string; error: string; recoverable: boolean }
  | { type: "cost.updated"; sessionKey: string; tokens: TokenUsage; costUsd: number };

4. UI Requirements — Multi-Agent Additions

These additions layer on top of the v1 feature set. All v1 Tier 1 features remain.

4.1 Unified Agent Roster (replaces Agent List for v2)

What changes: The agent list now shows both OpenClaw sessions and ACP sessions in a unified view, with visual distinction:

Badge	Meaning
🤖 Ada	Native OpenClaw agent session
🔵 Claude Code	ACP session via `agentId: "claude"`
🟢 Codex	ACP session via `agentId: "codex"`
🔴 Gemini	ACP session via `agentId: "gemini"`
⚪ OpenCode	ACP session via `agentId: "opencode"`

Filter controls: filter by agent type, status, cwd (project), date range.

Grouping: Sessions dispatched to multiple agents for the same task should be groupable by "task" (a Mission Control concept — stored in Task Map DB table).

4.2 Agent Dispatch Panel (new, Tier 1 for v2)

A first-class UI panel (not just a modal) for dispatching work to coding agents:

Elements: - Agent picker: card grid showing all available agents with status dots (AionUi-style) - Task textarea: the prompt/instruction - Project selector: cwd dropdown (pre-populated from recent cwds + git repos detected in workspace) - Options panel (collapsed by default): - Mode: oneshot / persistent - Permission mode: approve-all / approve-reads / deny-all - Model override (optional) - Max budget USD (optional) - Max turns (optional) - "Dispatch to N agents" toggle: send same task to multiple agents simultaneously for comparison - Submit button → calls AgentDispatcher.dispatch()

After dispatch: - Session appears immediately in Unified Agent Roster - Inspector panel opens automatically - If multi-agent dispatch: cross-agent comparison view opens

4.3 Per-Agent Task View with Live Output

Enhancement to Session Inspector: - For ACP sessions, show the raw agent output stream (the message.chunk events) in a terminal-like scroller with syntax highlighting - Tool calls shown as collapsed cards (expand to see input/output) - Permission prompt indicators (yellow warning if agent hit a permission boundary) - "Steer" input: send a steer instruction to the running session without interrupting context - Token counter and cost meter (live, from cost.updated events)

4.4 Cross-Agent Comparison View (new, Tier 2)

When a task was dispatched to multiple agents:

Task: "Refactor auth module to use Better Auth"
CWD: /workspace/mission-control

┌─────────────────────┬─────────────────────┬─────────────────────┐
│ Claude Code          │ Codex               │ Gemini CLI          │
│ ✅ Complete (4m 23s) │ 🔄 Running (2m 11s) │ ✅ Complete (3m 02s) │
│ $0.24               │ $0.11               │ $0.00 (free tier)   │
├─────────────────────┼─────────────────────┼─────────────────────┤
│ [output stream]     │ [output stream]     │ [output stream]     │
│ 14 tool calls       │ 8 tool calls        │ 11 tool calls       │
│ 3 files modified    │ 2 files modified    │ 3 files modified    │
└─────────────────────┴─────────────────────┴─────────────────────┘

[Accept Claude Code result] [Accept Gemini result] [Merge manually]

4.5 Agent Status Panel (new, Tier 1 for v2)

Sidebar or header widget showing availability of each configured agent: - Green dot: agent available, 0 active sessions - Yellow dot: agent busy (N active sessions) - Red dot: agent errored or unconfigured - Click: shows recent sessions for that agent

5. Tech Stack Recommendation

The v1 stack recommendation is correct and carries forward. These additions apply for v2:

5.1 No changes to core stack

Frontend: Next.js + React (unchanged)
Backend: Node.js + Hono (unchanged)
Realtime: Native WebSocket (unchanged)
Database: SQLite + Drizzle ORM (unchanged)
Auth: Better Auth (unchanged)
Deployment: Docker Compose on Proxmox LXC behind Traefik (unchanged)

5.2 New: Task Map table in SQLite

CREATE TABLE tasks (
  id TEXT PRIMARY KEY,
  title TEXT NOT NULL,
  prompt TEXT NOT NULL,
  cwd TEXT,
  created_at INTEGER NOT NULL,
  status TEXT NOT NULL  -- "pending" | "running" | "complete" | "error"
);

CREATE TABLE task_sessions (
  task_id TEXT NOT NULL REFERENCES tasks(id),
  session_key TEXT NOT NULL,  -- OpenClaw session key
  agent_id TEXT NOT NULL,     -- "claude" | "codex" | "gemini" | etc.
  dispatched_at INTEGER NOT NULL,
  PRIMARY KEY (task_id, session_key)
);

This is the only new data model needed. Everything else flows from the gateway.

5.3 New: Agent Manifest table in SQLite

CREATE TABLE agent_manifest (
  agent_id TEXT PRIMARY KEY,
  display_name TEXT NOT NULL,
  icon TEXT,
  enabled INTEGER NOT NULL DEFAULT 1,
  max_concurrent INTEGER NOT NULL DEFAULT 4,
  -- Live state (updated from gateway events)
  status TEXT NOT NULL DEFAULT "available",
  active_sessions INTEGER NOT NULL DEFAULT 0,
  last_used_at INTEGER
);

Pre-populated from acp.allowedAgents on startup. Live state updated from session events.

5.4 Consider: Terminal emulator in Session Inspector

For the live output view (ACP coding agents produce terminal-style output), consider xterm.js for the output renderer. The robsannaa/openclaw-mission-control repo already uses xterm.js + Monaco Editor for this purpose — strong prior art.

npm install @xterm/xterm @xterm/addon-fit @xterm/addon-web-links

This gives proper ANSI color rendering, scroll buffering, and copy-to-clipboard for coding agent output.

6. Phased Build Plan

Phase 0: Foundation (Week 1–2) — Unchanged from v1

All v1 Phase 0 work. No changes.

Additional deliverable for v2: - [ ] acpx plugin installed and verified: openclaw plugins install acpx && /acp doctor - [ ] At least one ACP agent confirmed working: /acp spawn codex --mode oneshot with a test task - [ ] Agent Manifest table seeded from acp.allowedAgents

Phase 1: MVP (Week 3–6) — Modified from v1

Week 3: F1 (Agent List → Unified Roster) + F7 (Event Stream) + F9 (Auth) - v2 addition: Unified roster shows both OpenClaw sessions and ACP sessions with agent type badges - v2 addition: Agent Status Panel in header (availability per agent)

Week 4: F2 (Session Inspector) + F3 (Agent Spawn → Agent Dispatch Panel) + F4 (Session Control) - v2 addition: Dispatch Panel replaces basic Spawn dialog — supports agent picker + ACP options - v2 addition: Inspector shows terminal-style output for ACP sessions (xterm.js) - v2 addition: Steer input in Inspector for running ACP sessions

Week 5: F5 (Cron Viewer) + F6 (Cost Dashboard) - Cost dashboard now shows per-agent-type breakdown (OpenClaw vs. Claude Code vs. Codex vs. Gemini)

Week 6: F8 (Alerts) + F10 (Mobile) + integration testing - All v1 acceptance criteria apply - v2 addition: ACP session errors trigger alerts with agent-specific context - v2 addition: Dispatch Panel works on mobile (simplified card picker, full form on desktop)

Phase 1 v2 Definition of Done: - Sean can dispatch a task to Claude Code from the UI, watch it run, see the output - All ACP sessions visible alongside OpenClaw sessions in unified roster - Mobile dispatch works (pick agent + write prompt from phone) - Task Map correctly groups dispatched sessions

Phase 2: Enhanced (Week 7–12) — Modified from v1

Milestone 2.1 (Week 7–8): Operational Power — same as v1 + ACP controls - Add: ACP session controls UI (cancel, steer, close, set model, set permissions) - Add: Permission mode picker per dispatch (approve-all / approve-reads / deny-all) - Add: cwd management — "projects" list that remembers recent working directories

Milestone 2.2 (Week 9–10): Multi-Agent Dispatch - NEW: Cross-Agent Comparison View — dispatch same task to N agents, side-by-side - NEW: Task-based grouping — kanban shows "task" cards, each with N agent sub-sessions - GitHub integration: link task dispatches to GitHub issues/PRs - Session search now spans ACP session transcripts

Milestone 2.3 (Week 11–12): Analytics + Polish - NEW: Per-agent analytics — which agent completes faster? cheaper? better tool usage patterns? - NEW: Agent comparison chart — cost/time/turn-count across agents for similar tasks - Multi-Agent Pipeline Builder (v1 Tier 2 feature F13) - Security audit pass - Visual polish

Phase 3: Advanced (Week 13+) — Modified from v1

Performance: - xterm.js virtualization for very long agent outputs - Session archival: move completed ACP transcripts to cold storage after 90 days

Advanced Multi-Agent Features: - Agent Router — automated selection: given a task type, auto-pick the best agent based on historical performance data - Agent A/B Testing — systematic comparison runs with statistical analysis - Cost optimization — suggest switching agents based on cost/quality trends - Webhook triggers — dispatch coding tasks from GitHub webhooks (PR opened → auto-dispatch analysis)

Tier 3 Features — priority order same as v1 (voice, 3D graph, predictive cost, etc.)

7. Repos to Leverage

From the 51 repos analyzed, these are the highest-value references or forks:

Primary: Fork this as your base

builderz-labs/mission-control (2,036 ⭐) - Next.js 16 + React 19 + SQLite ✅ (matches Sean's stack) - 28 panels, multi-gateway, role-based access, E2E tests ✅ - Already handles OpenClaw session events - Action: Fork and add ACP session type awareness + Dispatch Panel

Reference implementations (don't fork, study)

Repo	What to learn from it
AionUi (18k ⭐)	Agent picker UX, multi-agent cowork patterns, how they handle concurrent sessions
agentsview (424 ⭐)	Data model for multi-agent session indexing and full-text search
Claw-Kanban (43 ⭐)	Direct precedent for routing tasks to Claude Code/Codex/Gemini. Plugin architecture worth studying.
robsannaa/mission-control (401 ⭐)	xterm.js + Monaco + @xyflow/react in an OpenClaw dashboard. Rich UI components.
clawport-ui (261 ⭐)	@xyflow/react org-map for multi-team/multi-agent graph view. Voice confirmed.
openclaw-dashboard (tugcantopaloglu) (343 ⭐)	Only one with TOTP MFA. Study auth implementation. Zero-npm-deps SSE.
openclaw-nerve (173 ⭐)	Voice TTS/STT + kanban + CodeMirror 6 + file browser. Most feature-rich Vite+React dashboard.
claude-task-viewer (482 ⭐)	Reads `~/.claude/` filesystem directly with chokidar file watcher — useful pattern if we ever want a fallback for Claude Code sessions not going through acpx

Key npm packages to pull in

{
  "@xterm/xterm": "live output rendering for coding agents",
  "@xterm/addon-fit": "auto-resize terminal",
  "@xyflow/react": "pipeline builder / agent graph view",
  "dagre": "auto-layout for agent flow diagrams",
  "croner": "cron expression parsing and preview",
  "better-auth": "auth with TOTP",
  "drizzle-orm": "type-safe SQLite queries",
  "hono": "lightweight API server",
  "pino": "structured logging"
}

8. Estimated Effort

Phase	Duration	Key v2 additions	Complexity
Phase 0	2 weeks	acpx setup + verification, Agent Manifest seeding	Low
Phase 1	4 weeks	Unified Roster, Dispatch Panel, xterm.js output, Task Map	Medium
Phase 2.1	2 weeks	ACP controls UI, permission mode, cwd projects	Low-Medium
Phase 2.2	2 weeks	Cross-agent comparison, task grouping, GitHub link	Medium-High
Phase 2.3	2 weeks	Per-agent analytics, pipeline builder	Medium
Phase 3	Ongoing	Agent router, A/B testing, webhooks	High

Total to functional multi-agent mission control: ~10 weeks (Phases 0–2.2)

Comparison to building from scratch without ACP: If we had to manage subprocess lifecycles, parse CLI output for each agent, and build our own event normalization, estimate 2–3× the effort. ACP gives us all of that for free.

9. Open Questions

Must resolve before Phase 1 begins

acpx plugin status — Is acpx already installed and configured on Sean's OpenClaw instance? Run /acp doctor to check. If not, openclaw plugins install acpx + config. This is a blocker.
Also verify which agents are in acp.allowedAgents in openclaw.json
Confirm permissionMode setting (recommend approve-all for unattended coding tasks)
Base repo decision — Fork builderz-labs/mission-control or build from scratch?
Recommendation: Fork. It's Next.js 16 + SQLite, already handles gateway events, has 28 panels and role-based access. Starting from here saves 2–3 weeks of foundation work.
Risk: their data model may need significant refactoring for task grouping / ACP session types
Alternative: scaffold from scratch with create-next-app — full control, no tech debt
Gateway API discovery — We need to confirm the exact REST endpoint signatures for:
POST /sessions with runtime: "acp" (what does the body look like from the gateway's perspective?)
POST /acp/cancel, /acp/steer, /acp/close — do these exist as REST endpoints or only as gateway commands?
Action: Run openclaw gateway --help or check gateway docs to confirm REST API shape before implementing AgentDispatcher

Must resolve before Phase 2 begins

Cross-agent comparison UX — Prototype needed. How does the side-by-side view work when agent outputs are very long? Do we show full transcripts or just summaries? Does the user "accept" one agent's result? How does that work for code changes (git diff view needed)?
Agent performance data model — Before we can build "which agent is better for X task type?", we need to define what "better" means: faster? cheaper? fewer tool failures? higher git diff quality? Needs a scoring model decision.
cwd discovery — The Dispatch Panel needs a project list. Where does it come from?
Option A: Manual entry only
Option B: Scan /workspace and detect git repos
Option C: Maintain a "projects" list in SQLite (user-curated)
Recommendation: Option C with Option B as seed

Nice to have before Phase 3

ACP streaming format — Confirm what stream.coalesceIdleMs and stream.maxChunkChars produce from the gateway WebSocket. Do we get raw claude/codex stdout? Structured events? This affects xterm.js rendering fidelity.
Multi-gateway support — The builderz-labs/mission-control has multi-gateway support. Is this relevant for Sean (multiple OpenClaw instances)? Probably not yet, but worth keeping the data model open.

10. Implementation Checklist Additions (over v1)

Pre-Phase 1 Verification

# 1. Confirm acpx is installed
openclaw plugins list | grep acpx

# 2. Check allowed agents
grep allowedAgents ~/.openclaw/openclaw.json

# 3. Test ACP dispatch manually
/acp spawn codex --mode oneshot "List the files in the current directory"

# 4. Confirm ACP session appears in gateway
curl http://localhost:18789/sessions -H "Authorization: Bearer $TOKEN" | jq '.[] | select(.key | startswith("agent:") and contains(":acp:"))'

# 5. Confirm session events flow on WebSocket
# (watch gateway WebSocket, should see session.created, message.chunk, session.ended)

New DB Migrations Required

-- Add to Phase 0 schema
CREATE TABLE tasks (id, title, prompt, cwd, created_at, status);
CREATE TABLE task_sessions (task_id, session_key, agent_id, dispatched_at);
CREATE TABLE agent_manifest (agent_id, display_name, icon, enabled, max_concurrent, status, active_sessions, last_used_at);

-- Mark ACP sessions in existing sessions table
ALTER TABLE sessions ADD COLUMN agent_type TEXT DEFAULT "openclaw";
-- Values: "openclaw" | "claude" | "codex" | "gemini" | "opencode" | "pi" | "kimi"

New API Routes Required

POST /api/tasks              → create task, dispatch to N agents
GET  /api/tasks              → list tasks with linked sessions
GET  /api/tasks/:id          → task detail with all agent sessions
POST /api/tasks/:id/dispatch → dispatch existing task to additional agent
GET  /api/agents             → list agents from manifest with live status
POST /api/agents/:id/cancel  → cancel all active sessions for agent
DELETE /api/tasks/:id        → cancel task, close all linked ACP sessions

11. Success Metrics — v2 Additions

Phase 1 v2 (Week 6)

Dispatch a Claude Code task from UI → session runs → output streams → completes
Same for Codex, Gemini (confirms multi-agent dispatch works)
Unified roster shows all agent types with correct status badges
Zero ACP sessions invisible to Mission Control (100% coverage)

Phase 2.2 (Week 10)

Same task dispatched to 2+ agents simultaneously, comparison view renders correctly
Task map correctly groups N sessions per task
Cost comparison across agents visible per task

12. What Changed from v1

Area	v1	v2
Agent Spawn	Basic modal, OpenClaw sessions only	Full Dispatch Panel, any ACP agent, multi-agent dispatch
Session List	OpenClaw sessions only	Unified roster: OpenClaw + all ACP agent types
Session Inspector	Message timeline	+ xterm.js output for ACP, steer input, permission mode indicator
Data model	sessions, events, cron, alerts, users	+ tasks, task_sessions, agent_manifest
Architecture	Gateway Adapter → Event Bus	Same + Agent Dispatcher for outbound ACP dispatch
Integration work	None for coding agents (future)	ACP already works; Dispatch Panel is the main new surface
Phase 1 scope	OpenClaw monitoring	OpenClaw monitoring + coding agent dispatch + output streaming
New packages	—	xterm.js, @xyflow/react (Phase 2)

13. Final Recommendation

Build Phase 0–1 of v2 before committing to Phase 2+. The single most important milestone is:

Sean dispatches a Codex task from the Mission Control UI, watches the output stream in real-time, and sees the completed session in the unified roster alongside his OpenClaw agents.

Once that works, the multi-agent mission control is real. Everything else (cross-agent comparison, analytics, task routing) is additive.

The hardest unknown is whether the builderz-labs/mission-control fork is the right base or if scaffolding from scratch is cleaner. Recommend: spend 2 days trying to fit their data model to our requirements; if it's too rigid, start fresh but keep their component library as reference.

The easiest win is the acpx integration — if the plugin is already installed, dispatching to coding agents works out of the box. The Mission Control just needs to call the gateway REST API correctly.

End of OpenClaw Mission Control Implementation Plan v2.0
Research basis: 51 repos analyzed, OpenClaw ACP/CLI docs read, Claude Code CLI reference confirmed, Codex + Gemini CLI READMEs reviewed, AionUi/agentsview prior art confirmed.
Ready for implementation handoff. Run the pre-Phase 1 verification checklist first.

🕸️ Ada Research Browser